先記住：畫面欄位不等於 API 契約，先問資料語意與權威。
需要深入時：再整理 DTO、領域與畫面模型。

畫面有六個欄位，不代表 API 只要六個欄位

設計稿上的購物車只有商品名、單價、數量、小計、折扣和總額。

你說需要這六個欄位，後端說沒問題。
但開始串接時才發現沒有幣別、沒有可追蹤的商品識別，也不知道價格是哪個版本。

原來資料模型不是把畫面文字抄成 interface，而是弄清楚每個值代表什麼、從哪裡來，以及什麼時候會失效。

先分三種資料

DTO 是跨 API 傳輸的形狀，依契約定義。
領域資料表達我們在功能中真正關心的概念，例如購物車項目與有效報價。
畫面模型則是呈現需要的格式，例如「NT$ 1,200」與按鈕是否可用。

不一定每個小功能都要建立三個檔案，但腦中要分清楚。
否則 UI 一旦直接依賴後端的巢狀結構，API 改名字就會一路改到畫面。

從問題建立契約草案

我會先列一張欄位筆記，這些是教學提案，並非現有 API：

• itemId：穩定識別一個購物車項目；不能用列表索引取代。
• quantity：允許的範圍、是否限整數，需要產品規則。
• amount 與 currency：金額單位、精度、捨入規則要一起定義。
• quoteVersion：讓報價能對應購物車狀態；具體機制與後端確認。
• expiresAt：若報價有期限，要確認時區與過期後行為。

接著再往下追問 null 和缺欄位分別是什麼意思。
「沒有優惠」可能合法；「讀取失敗所以不知道優惠」是另一回事。
不能統一補成零，否則總額看起來完整卻不可信。

API 沒完成，仍能分階段交付

現在可以先估並完成表單、互動流程、資料需求清單與 Mock 情境。
Mock 要明確標成契約草案，不能被當成後端已支援的事實。

等契約確認後，再完成 Adapter 與整合驗證。
如果後端報價必須一次回傳全部欄位，前端就不要把兩次請求的總額和折扣拼在一起；它們可能來自不同版本。

估算時把「不依賴 API 的工作」和「依賴契約的工作」分開。
前者可先進行，後者留下假設與重新估算的觸發條件。

可以交給 AI 的 Prompt

請根據購物車畫面需求提出資料需求表，包含欄位意義、來源、可空性、格式、權威來源與失效時機。請分開傳輸 DTO、領域概念與畫面格式。尚未確認的欄位標示提案，不生成真實端點。再列出可先做的 UI 工作，以及契約確認後才能完成的串接工作。

這個 Prompt 的 SA 重點是語意與責任。
請 AI 幫你列欄位很容易，真正要檢查的是它是否把「想要的資訊」誤寫成「已存在的契約」。

今日練習與筆記

選一個金額欄位，寫出單位、精度、null 意義、資料來源與何時過期。
如果其中一格寫不出來，把它當成需要對齊的問題。

開發時也不需要先追求完美模型，只求模型能暴露未知。
明天會處理跨團隊依賴：當契約和設計還會變，怎樣溝通比較有用。